REMARKS 



Claims 1, 11, 18, 29, 34, 35, 45, 52, and 62. have been amended. Claims 10, 28, 
44, and 61 have been canceled. Claims 1-9, 11-27, 29-43, 45-60 and 62-68 are pending 
in the application. Reconsideration is respectfully requested in light of the following 
remarks. 

Section 101 Rejection ; 

The Examiner rejected claim 34 under 35 U.S.C. § 101 as being directed to non- 
statutory subject matter. The Examiner asserted that the claim is directed to software per 
se, not physical things. However, the elements of amended claim 34 are all expressed as 
means for performing a specified function. Applicants remind the Examiner that under 
35 U.S.C. § 112, paragraph 6: 

An element in a claim for a combination may be expressed as a means or 
step for performing a specified function without the recital of underlying 
structure, material, or acts in support thereof, and such claim shall be 
construed to cover the corresponding structure, material, or acts described 
in the specificatoin and equivalents thereof 

Thus, by statutory definition, the means claim specifically includes structure or material 
(physical things) in support thereof and cannot be construed as software per se. 
Therefore, for at least the reasons presented above, the § 101 rejection of claim 34 is 
improper and removal thereof is respectfully requested. 

Section 102fb) Rejection ; 

The Examiner rejected claim 34 under 35 U.S.C. § 102(b) as being anticipated by 
Monday et al. (U.S. Patent 6,263,377) (hereinafter "Monday"). Applicants respectfully 
traverse this rejection for at least the following reasons. 

Contrary to the Examiner's assertion, Monday does not teach or suggest default 
class loader means for a virtual machine, wherein the default class loader means is 
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configured to load classes for code executable within the virtual machine on the system 
from one or more local locations indicated by a class path of the default class loader 
means. The Examiner provides "CLASSLOADER, checks the environment variable 
CLASSPATH for... to the requesting application; col. 3, lines 38-44" in support of the 
assertion that Monday teaches this element from claim 34. 

Monday discloses a distributed application manager running at a local computer 
system that keeps a list of available distributed applications and a list of servers from 
which the distributed applications can be downloaded. The distributed application 
manager presents a selection screen to the user containing a list of available distributed 
applications. Based on a user selection from the list, the distributed application manager 
searches for the distributed application on a path of servers and a path of directories in 
each server. When the distributed application manager finds the selected application, it 
downloads the application from the server, installs the selected application at the local 
computer system and invokes the application for the user. (Monday, Absfract). 

In col. 3, lines 38-56, Monday further describes operations of the distributed 
application manager in reference to FIG. 2. In this citation, Monday states that the 
distributed application manager checks the environment variable CLASSPATH for a set 
of directories to browse for a selected class file (selected via user selection from a list on 
a selection screen as described above). If the selected x.class is located, then the 
distributed application manager reads the file in, parses it, and returns a pointer to the 
requesting application. If the selected x.class is NOT located, then a subclass of the 
CLASSLOADER, a REMOTECLASSLOADER checks if a REMOTECLASSPATH is 
set as indicated at block 204 in FIG. 2. The environment variable 
REMOTECLASSPATH contains a set of servers 122, ftp locations and/or machine 
names and directory paths on those machines, which may contain the relevant classes. 
The distributed application manager 132 then checks each server 122 in sequence for the 
particular selected x.class file as indicated at block 204 in FIG. 2. If the class is found, the 
x.class file is written to the first CLASSPATH directory, thus building the class locally so 
that the "network does not have to be consulted on the next run". 
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Monday, in the above description of a distributed application manager that allows 
users to select an application and then, if necessary, loads the application from a remote 
server, is clearly not describing default class loader means for a virtual machine, wherein 
the default class loader means are configured to load classes for code executable within 
the virtual machine on the system from one or more local locations indicated by a class 
path of the default class loader means. Applicants refer the Examiner to the Background 
section of the present application, specifically page 1, lines 18-26, where Applicants 
disclose the defauh class loader of an exemplary virtual machine, the Java Virtual 
Machine (JVM). Applicants' claim 34 is referring to such a default class loader for a 
virtual machine (e.g., a JVM). 

Furthermore, contrary to the Examiner's assertion, Monday does not teach or 
suggest means for determining that a class needed to execute the code on the system is 
not stored in the one or more locations indicated by the class path; means for obtaining 
the class from a remote system via a network; and means for storing the class in a 
location on the system indicated by the class path of the default class loader means; 
wherein said means for determining, said means for obtaining, and said means for 
storing are configured to operate separate from and transparent to the default class 
loader; and wherein the default class loader means is configured to load the class from 
the location indicated by the class path. In claim 34 of the present application, said 
means for determining that a class needed to execute the code on the system is not stored 
in the one or more locations indicated by the class path, said means for obtaining the 
class from a remote system via a network, and said means for storing the class in a 
location on the system indicated by the class path of the default class loader means are all 
performed separately from and fransparently to the default class loader means for the 
virtual machine. The default class loader means attempts to load a class from a class path 
of the default class loader means. If the class is not located, the recited means in claim 34 
determine that a class needed to execute the code on the system is not stored in the one or 
more locations indicated by the class path, obtain the class from a remote system via a 
network, and store the class in a location on the system indicated by the class path of the 
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default class loader means. These operations are separate from and fransparent to the 
default class loader means. The default class loader means may then load the class from 
the location on the system indicated by the class path. 

Page 1, line 10-page 3, line 5 of the Background section of the instant application 

generally describes the dynamic loading of classes using class loaders in the prior art. In 

page 1 line 28 - page 2 line 12, Applicants describe the concept and general operations of 

custom class loaders in virtual machines. The first part of this section states: 

Virtual machines such as JVM may provide a facility by which a user can 
introduce a custom class loader. For example, in JVM, a hook is provided 
to the loading mechanism through the custom class loaders . 
Programmatically speaking, [custom] class loaders are ordinary objects 
that may be defined in code (e.g. Java™ code). In Java™, [custom] class 
loaders are instances of subclasses of absfract class Classloader . 

A conventional mechanism for dynamically loading classes not available on the 

class path of the default class loader for a virtual machine is via custom class loaders, as 

is described on page 3, lines 4-5 of the present application: 

In Java, to use a class, the class has to be in the class path of the default 
class loader, or alternatively a custom class loader may be provided. 

Claim 34 of the instant application recites means for implementing a mechanism 

to remotely load classes needed to run, for example, an application in a distributed 
computing environment through the default class loader of the virtual machine (i.e., not a 
custom class loader(s) to remotely load the classes) (see, for example, page 3, lines 9-11 
and page 4, lines 3-1 1 of the present application). 

In confrast, what the Monday reference describes in col. 3, lines 38-56 and 
elsewhere is the use of a custom class loader as disclosed in the background section of the 

present application. In the cited section, Monday states "If x. class is NOT located, then a 
subclass of the CLASSLOADER , a REMOTECLASSLOADER..." In the background 
section of the present application, as noted above. Applicants explain that custom class 
loaders are instances of subclasses of abstract class Classloader . When Monday refers to 
REMOTECLASSLOADER, Monday is referring to a custom class loader. Monday's 
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system uses a custom class loader in the conventional method as described in the 
background section of the present application to load classes not found on the class path 
of Monday's CLASSLOADER. 

Thus, what Monday discloses is clearly and distinctly different than what is 
recited in claim 34 of the present application. Monday's system is actually described as 
operating according to the conventional method for loading classes that relies on custom 
class loaders . Monday's REMOTECLASSLOADER is simply a custom class loader as 
described in Applicants' background section. Applicants' specification discloses a 
method for loading classes that intentionally does not rely on the conventional method in 
virtual machines using custom class loaders to avoid problems created thereby; instead, 
Applicants' disclosed method transparently determines or detects that a class has not been 
loaded from a location on the class path of the default class loader, locates the class, 
obtains the class, and stores the class in the location indicated by the class path of the 
default class loader without using custom class loaders. The default class loader may 
then load the class from the location indicated by the class path of the default class 
loader. This is the method recited in the means elements of claim 34. 

In summary, Monday, in disclosing a distributed apphcation manager , clearly is 
not directed at a default class loader means for a virtual machine as is recited in claim 
34. Furthermore, Monday describes a method that relies on a custom class loader, while 
claim 34 recites means for implementing a method for remotely loading classes that does 
not rely on a custom class loader . Also, Monday does not teach that means for 
determining that a class needed to execute the code on the system is not stored in the one 
or more locations indicated by the class path, means for obtaining the class from a remote 
system via a network, and means for storing the class in a location on the system 
indicated by the class path of the default class loader means are all performed separately 
from and fransparently to the default class loader means for the virtual machine . Clearly, 
Monday does not anticipate claim 34 of the instant application. 
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Thus, for at least the reasons presented above, the § 102(b) rejection of claim 34 
is not supported by the cited prior art and removal thereof is respectfully requested. 

Section 103fa) Rejections : 

The Examiner rejected claims 1-8, 10-13, 16, 35-59, 61-64 and 67 under 35 
U.S.C. § 103(a) as being unpatentable over Monday in view of Venners ("Inside the Java 
Virtual Machine"). Apphcants respectfully traverse this rejection for at least the 
following reasons. 

Regarding claim 1, contrary to the Examiner's assertion, tlie cited references 
fail to disclose, alone or in combination, do not teach or suggest what is recited in 
amended claim 1. Applicants' above arguments regarding the § 102(b) rejection of 
claim 34 in light of the Monday reference apply equally to the Examiner's rejection of 
claim 1 in light of the Monday reference. To summarize the above arguments, Monday, 
in disclosing a distributed application manager , clearly is not directed at a default class 
loader for a virtual machine as is recited in claim 1 . Furthermore, Monday describes a 
method that relies on a custom class loader, while claim 1 recites a system that 
implements a remote class loader mechanism for remotely loading classes that does not 
rely on a custom class loader . 

In regards to the Venners reference, page 1, line 10-page 3, line 5 of the 

Background section of the instant application generally describes the dynamic loading of 

classes using class loaders in the prior art. In particular, page 3, lines 4-5 describes that: 

In Java, to use a class, the class has to be in the class path of the default 
class loader, or altemativelv a custom class loader mav be provided . 

The Venners reference is an overview of the Java Virtual Machine (JVM). 
Chapters 1-4 "give a broad overview of Java's architecture". A carefiil review of the 
Venners reference, particularly an overview given in Chapter 3, page 2, shows that 
Venners' description of Java's method of loading classes using class loaders is consistent 
with what is described in the Background section of the instant application . For example, 
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Venners, in Chapter 3, page 2, gives the following description of how Java's class 

loading mechanism works: 

Imagine that during the course of running the Java application, a request is 
made of your [custom] class loader to load a class named Volcano. Your 
[custom] class loader would first ask its parent, the class path class 
loader, to find and load the class. The class path class loader, in tum, 
would make the same request of its parent, the installed extensions class 
loader. This class loader, would also first delegate the request to its parent, 
the bootstrap class loader. Assuming that class Volcano is not a part of the 
Java API, an installed extension, or on the class path, all of these class 
loaders would return without supplying a loaded class named Volcano. 
When the class path class loader responds that neither it nor any of its 
parents can load the class [i.e., the requested class is not on a class path], 
your [custom] class loader could then attempt to load the Volcano class in 
its custom manner, by downloading it across the network. Assuming your 
[custom] class loader was able to download class Volcano, that Volcano 
class could then play a role in the appUcation's future course of execution. 

In contrast to the above description from Venners, claim 1 of the instant 
application recites that a default class loader for a virtual machine determines that a class 
needed to execute code on the system is not stored in one or more local locations 
indicated by the class path (and thus fails to load the class). An indication is generated 
that the class is not loaded. A remote class loader mechanism then, transparently to the 
default class loader of the virtual machine, detects the indication, obtains the class from a 
remote system via a network, and stores the class in a location indicated by the class path. 
The default class loader (not a custom class loader, as in the Venners reference and the 
Monday reference, and as the Java class loading mechanism described by Venners and 
described in the Background section of the instant application operates) then loads the 
class from the location indicated by the class path . 

To summarize, Venners discloses that, if the "default class loader" (class path 
class loader) cannot locate a class in a location on its class path, the "default class 
loader" notifies a "custom class loader" associated with the class, which then attempts to 
load the class, possibly from a remote location. Similarly, the Monday reference 
describes, in col. 3, lines 38-56, a REMOTECLASSLOADER that clearly operates as a 
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conventional custom class loader as is disclosed in Venners and in the background 
section of the present application. 

In contrast, claim 1 of the instant application recites that, if the "default class 
loader" cannot locate a class in a location on its class path, a "remote class loader 
mechanism", transparently to the default class loader, determines that the class was not 
located on the class path of the default class loader, locates the class on a remote system, 
and stores the class in a location indicated by the default class loader's class path. The 
defauh class loader then loads the class from the location. 

Thus, what claim 1 of the instant application recites is clearly distinct from the 
Java class loading mechanism as described by the Venners reference and from Monday's 
disclosed system. 

Applicants remind the Examiner that, to establish a prima facie case of 
obviousness of a claimed invention, all claim limitations must be taught or suggested by 
the prior art . In re Royka, 490 F.2d 981, 180 U.S.P.Q. 580 (C.C.P.A. 1974), MPEP 
2143.03. As shown above, the cited art does not teach or suggest all limitations of claim 
1. For example, the cited references, alone or in combination, do not teach or suggest 
that, if the "default class loader" cannot locate a class in a location on its class path, a 
"remote class loader mechanism" that is not a custom class loader locates the class on a 
remote system and stores tlic class in a location indicated by the default class loader's 
class path transparently to the default class loader , and that the default class loader then 
loads the class from the location. 

Furthermore, the Examiner's stated motivation for combining the references, 
"because Verniers teaches the details how a Java application load and utilize class that are 
needed at runtime", is clearly not a motivation for combining the references. It is if 
anything simply a "motive" for understanding how the Monday system already works , 
since the Monday system already employs the conventional class loading method 
described in Venners . Furthermore, the present application describes the conventional 
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method for dynamically loading classes in virtual machines such as JVMs as is described 
in Venners, and clearly discloses a system and method that is distinctly different than the 
conventional method described in Venners. Claim 1 of the instant application clearly 
recites elements that enable the distinctly different method described in AppUcants' 
specification. Moreover, the Examiner's stated motivation is merely conclusory. 

Furthermore, even if the Monday and Venners references were combined, 
the combination would not produce anything lil^e was is recited in claim 1 of the 
present application. It would simply produce a system that handles the loading of 

classes using the Java class loading method as disclosed in Venners, which it is clear that 
Monday's system already uses. In other words, it would simply produce the Monday 
system as disclosed in the Monday reference. Since the Monday reference already 
employs the class loading mechanism disclosed in Venners, there is and can be no 
motivation to combine the references in any case. 

Thus, for at least the reasons presented above, the rejection of claim 1 is not 
supported by the cited prior art and removal thereof is respectfully requested. Similar 
remarks as those above regarding claim 1 also apply to claims 35 and 52. 

The Examiner rejected claims 9, 14, 15, 17-33, 60, 65, 66 and 68 as being 
unpatentable over Monday in view of Venners, and fiirther in view of Babaoglu, et al. 
("Anthill: A Framework for the Development of Agent-Based Peer-to-Peer Systems") 
(hereinafter "Babaoglu"). Applicants respectfully traverse this rejection for at least the 
reasons given above in regards to claim 1 . 

In further regard to claim 17, contrary to the Examiner's assertion, the cited 
references fail to disclose, alone or in combination, program instructions executable 
by a processor to implement wherein the system and the remote system are configured 
to participate in a distributed computing system on the network for submitting 
computational tasks in a distributed heterogeneous networked environment that utilizes 
peer groups to decentralize task dispatching and post-processing functions and enables 
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a plurality of jobs to be managed and run simultaneously. The Examiner simply asserts 
that Babaoglu teaches "peer-to-peer application can be implemented in Java (page 7, 
section 4)" and that "it would have been obvious. . .to apply the teachings of Babaoglu to 
the system of Monday because it presents a framework supporting a new approach for 
building P2P application in which resource can be sharing by direct exchange between 
peer nodes." 

The Babaoglu reference describes: 

...Anthill, a framework to support the design, implementation and 
evaluation of P2P applications based on ideas such as multi-agent and 
evolutionary programming borrowed from CAS. An Anthill system 
consists of a djoiamic network of peer nodes; societies of adaptive agents 
travel through this network, interacting with nodes and cooperating with 
other agents in order to solve complex problems. (Babaoglu, Abstract). 

However, the Examiner has simply asserted that "Babaoglu teaches "peer-to-peer 
application can be implemented in Java", and has not provided any argument or reference 
that Babaoglu teaches or suggests all of the claim limitations recited in claim 17 of the 
instant application. For example, the Examiner has provided no argument or reference, 
nor can the Applicants find anything, from the Babaoglu reference that teaches or 
suggests that the Babaoglu "Anthill" framework is a distributed computing system for 
submitting computational tasks in a distributed heterogeneous networked environment or 
that the Babaoglu "Anthill" framework decentralizes task dispatching and post- 
processins functions and enables a plurality of jobs to be manased and run 
simultaneously . 

Applicants remind the Examiner that, to establish a prima facie case of 
obviousness of a claimed invention, all claim limitations must be taught or suggested by 
the prior art . In re Royka, 490 F.2d 981, 180 U.S.P.Q. 580 (C.C.P.A. 1974), MPEP 
2143.03. As shown above, the cited art does not teach or suggest all limitations of claim 
1, from which claim 17 depends. 
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Furthermore, the Examiner's stated motivation for combining the references, 
"because it presents a framework supporting a new approach for building P2P application 
in which resource can be sharing by direct exchange between peer nodes", is not a 
motivation that is directly relevant to Monday's method and computer program product 
for managing distributed applications on a local computer system. It is not at all 
"obvious" how Monday's disclosed method would benefit from Babaoglu "Anthill" 
framework, nor is it obvious as to how Babaoglu' s "Anthill" framework could, or even if 
it could, be implemented in Monday's disclosed method. Furthermore, the stated 
motivation is not a motivation that is directly relevant to the functioning or 
application of what is recited in claim 17 of the instant application. Moreover, the 
Examiner's stated motivation is merely conclusory. 

Furthermore, as shown above, even if the Monday and Babaoglu references 
were combined, the combination would not produce anything like was is recited in 
claim 17 of the present application. 

Thus, for at least the reasons presented above, the rejection of claim 17 is not 
supported by the cited prior art and removal thereof is respectfully requested. Similar 
remarks as those above regarding claim 17 also apply to claim 51 and 68. 

Regarding independent claim 18, Applicants respectfully traverse this 
rejection for at least the reasons given above in regards to claim 1 and claim 17. 

Applicants also assert that the rejection of numerous ones of the dependent claims 
is further unsupported by the cited art. However, since the rejection has been shown to 
be unsupported for the independent claims, a further discussion of the dependent claims 
is not necessary at this time. 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and an early 

notice to that effect is requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5681- 
65900/RCK. 

Respectfully submitted. 



/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
Attorney for AppUcant(s) 
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